Since programming languages replaced punch-cards as a preferred means for providing programmatic instructions to computing devices, many languages, or derivatives thereof, have made programming more efficient and reliable. However, many organizations have discovered that the cost, effort and risk required to replace older legacy systems with modern systems is often overwhelming. Therefore, innovation has continued to support legacy systems in order to bridge gaps between the old and new computing technologies. This often includes modification of existing legacy programs and even using legacy programming languages to write new programs. COBOL is one such programming language that, in spite of newer object based programming languages, will likely remain a vital part of many organization's computing centers. However, COBOL lacks some of the flexibility that is intrinsic to the newer object based programming language, such as the ability to sequentially pass a varying number of parameters to another program and/or sub-program which has been configured to receive a defined range of parameters.
Within a COBOL program it may be possible to determine how many parameters have been passed to the program only in the first instance of the program's execution within a load module. In subsequent calls, the control blocks are not refreshed and so this process no longer works with any accuracy. For example, if a program is called the first time with 5 passed parameters, that value can be detected. If the next call only passes 3 parameters, interrogating the control blocks will typically still return a result of 5. The lack of accuracy in subsequent program calls makes it difficult to create very accommodating routines that may be passed a variable number of parameters within a load module's execution.
Typical Z/OS COBOL programming environments may comprise many main programs and sub-programs. Calling a sub-program often includes a pre-determined number of parameters to be passed by the main-program. Similarly, the program logic in the sub-program typically expects that exact number of parameters as input. Though this model may be acceptable for the vast majority of application programs, there may be instances where the number of parameters passed cannot be determined beforehand. For instance, a COBOL utility program serving different processing requirements cannot usually predetermine the number of parameters passed. Since there is no mechanism in the COBOL language to derive this number dynamically, a solution has been to replicate the sub-program many times, one for each expected combination of input parameters. However, this attempted solution often increases software cost and maintenance.
Another solution to this problem has been to call a utility program through a driver program written in assembler. Assembler, being a lower level language, has access to all the operating system registers which can be used to compute this number. The Assembler program in turn appends the count as an additional parameter and calls the actual sub-program. Though this method may be acceptable, it often required an unnecessary call to an artificial driver. Another alternative method was to modify the main program and pass the number of parameters as an additional parameter to the subprogram. However, this method usually involves hard coding this number in the main program and maintaining this number every time the call parameter is changed. Any out of sync errors between the count and the actual parameters passed can trigger serious system abends. Either alternative is very expensive when one upgrades one of the called modules in an existing application to accept a variable number of parameters without changing all the calling modules.
Other attempts were also made where the addresses of the input parameters were checked for null. However, in reusable programming, this sometimes turns out to be erroneous as the addresses are not initialized for every call. Therefore, a need exists for a system and method for run-time detection of input parameter counts in a Z/OS COBOL environment.